1. Field of the Invention
The present invention relates to computer networking. More specifically, the present invention relates to a method and an apparatus for communicating data using a socket interface with multiple transport layer implementations.
2. Related Art
The Internet has permeated almost all aspects of our lives—from buying books to buying real estate, and from reading a newspaper to watching a movie. The Internet owes its incredible success to a number of key technologies which include TCP (Transport Control Protocol) and IP (Internet Protocol) which are standard networking protocols used on the Internet, and the socket API (Application Programming Interface) which is a standard networking interface that applications use to communicate over a TCP/IP network.
Over the years, networking speeds on the Internet have increased exponentially, which have brought, in addition to well known advantages, new bottlenecks in computers and network devices. A number of new technologies have been proposed to alleviate these bottlenecks.
Unfortunately, some of these technologies threaten to significantly complicate the structure of a TCP stack in an OS (Operating System). One such technology involves a transport layer protocol called Socket Direct Protocol (SDP). Although SDP is a significantly different protocol from TCP, it proclaims to be fully compatible with the socket API that is traditionally used with TCP. Specifically, SDP requires an RDMA (Remote Direct Memory Access) capable transport, and claims to provide much better efficiency for socket-based applications. (Further details on SDP can be found at the RDMA Consortium's website. Supporting multiple transport layer implementations under the same socket interface gives rise to many technical challenges, such as, the problem of managing a common port-number space between the various transport layer implementations.
TCP Offload Engine (TOE), which offloads TCP-related computations from the processor, is another technology proposal that threatens to complicate the structure of a TCP stack. TOE provides full compatibility, both in the wire protocol, and in the API semantics with a traditional socket interface that works with TCP. Unfortunately, the industry is still debating as to how much TCP-related computation should be offloaded to the TOE, which has resulted in different companies offering different flavors of TOEs, each with vastly different capabilities. Again, this also creates technical challenges that essentially amount to supporting multiple transport layer implementations under the same socket interface.
A naïve approach to support multiple transports is to simply provide multiple transport stacks underneath the socket layer, i.e., one transport stack per TCP/SDP/TOE implementation. Since all of these transport stacks support the same AF_INET/SOCK_STREAM/IPPROTO_TCP sockets, for a socket application, some other mechanism must be used to select which transport to use. Unfortunately, this selection mechanism will most likely require the application to possess the knowledge of how to select the “right” transport, which can lead to difficult problems. Specifically, this approach may require changes to the application, which is often impossible or impractical.
To understand why, note that, on the listener side, most applications use a single listener process/thread to listen to connection requests on all network interfaces. In the naïve approach described above, an application may have to start multiple listener processes/threads, one for each type of transport implementation. This will most likely involve changing the application software, the cost of which can be prohibitive.
Another approach used to support multiple transports under a socket interface is to bind the application to a specific interface. For example, to support TCP and SDP, this technique requires the system administrator to allocate a separate IP address to the SDP physical interface and the TCP physical interface, and then the application has to specifically bind to the SDP or the TCP physical interface in order to use the corresponding protocol implementation. Since applications typically do not bind to a specific interface, this approach is likely to require changes to the application software which can be impractical or impossible.
Furthermore, supporting multiple transport implementations using present approaches is likely to duplicate vast amounts of code, since present approaches require each transport stack to be a full implementation of the transport protocol.
Hence, what is needed is a method and an apparatus for supporting multiple transport layer implementations under a socket interface without the above-described problems.